Clarify that the TI is a high level index and points to Libraries with DSI #26
Conversation
There was a problem hiding this comment.
This may (unnecessarily) constrain the potential use of TI without a concrete way to check/verify forClass or any of the data models actually used. Wouldn't the use of desired domain specific index (DSI) be still achievable irrespective to saying anything about it normatively?
While DSI can help Solid applications find items in a library, Solid applications are not or need not be limited to them to find objects.
Even if TI becomes limited to DSI, there'd still be a need to allow applications to simply find things with a specific class without necessarily being part of a higher model that's clear cut or readily available. For example, research data can be stored in many formats including documents, spreadsheets, databases, images, audio/video files, and more.
That aside, I think DSI exemplifies TI well, and that can be used to help the reader with what they may be familiar with. The text could can be revised with that in mind, but it shouldn't limit TI to DSI, in my opinion.
There was a problem hiding this comment.
#35 highlights an issue with the use of vcard:AddressBook example in the specification as the term is undefined.
While an address book is among a good example of such index, it can't be expressed with vCard as it stands without introducing new definitions (vcard:AddressBook or another).
To add to my point earlier point ( #26 (review) ) on constraining TI to high level index, I believe TI's use will hit the barriers quickly, e.g., with vcard:AddressBook not being defined.
I don't have data on the fitness of vocabularies that define both the high and index level as well as being useful for Solid applications - for devs to get things off the ground by reusing a vocabulary (today... not next month or years, or hypothetical future), and for individuals to use the applications.
To take the example from earlier, solid:forClass vcard:VCard would work just fine, and if and when fit domain specific indexes are available, they can still be used as it stands with the current TI.
(Again, I like the idea of explaining one way of using TIs with DSI but it shouldn't "clarify" that's the only purpose.)
Given the ease of minting new URIs (assuming appropriate vocab management), I don't think we should be too worried by not having existing terms for high level indices. solid:forClass vcard:VCard is too limiting in my opinion - it assumes that all vcards will be indexed in the same way, likely in a flat container What I find to be of greater concern is if an existing data standard does not allow new index terms to be defined. Shape trees discussed this as motivation for a link header rather than in-document shape definition. I think even in that case a workaround could be found by defining an external high level index as a type registration entry point. |
I think the problem of using new terms is not the difficulty on minting them, but the fragmentation that this creates and the likelihood of interoperability happening if everyone is creating their own terms. It makes perfect sense to add new types to express something that is not covered by existing terms, but whenever it's possible to use existing terms in the way they were intended; I'd prefer it. I suppose this wouldn't be such a problem if we had an easy way to declare and interpret equivalences between terms, but until that happens... I'm very reticent to mint new terms if I can avoid it. For example, to summarize what we talked about in the Umai issue. Right now, I can declare my recipes by registering an instanceContainer forClass |
|
Just making a connection to previous language: 2018 https://github.com/solid/solid/blob/main/proposals/data-discovery.md Possibly first reference Jan 2016: |
Clarify that Type Indexes are not used for every item, they lead to Data Libraries with other domain specific indexes which are different for every app.